Redis Request Routing

• 在Redis Server叢集中所有的操作透過Request Routing到正確的Master節點進行．

./redis-cli -h 127.0.0.1 -p 6310

# set key value 成功
127.0.0.1:6310> set book 123
OK

# set key value 失敗，因為hash_slot = 5787，應該在127.0.0.1:6320操作
127.0.0.1:6310> set book1 abc
(error) MOVED 5787 127.0.0.1:6320

# set key value 失敗，因為hash_slot = 9976，應該在127.0.0.1:6320操作
127.0.0.1:6310> set book2 def
(error) MOVED 9976 127.0.0.1:6320

# set key value 失敗，因為hash_slot = 14041，應該在127.0.0.1:6330操作
127.0.0.1:6310> set book3 ghi
(error) MOVED 14041 127.0.0.1:6330

# 透過 -c 來做Request Routing到正確的Master節點進行
./redis-cli -h 127.0.0.1 -p 6310 -c

# set key value 成功
127.0.0.1:6310> set book 456
OK

# set key value 成功，自動導向正確的Master節點操作
127.0.0.1:6310> set book1 abc
-> Redirected to slot [5787] located at 127.0.0.1:6320
OK

# set key value 成功，自動導向正確的Master節點操作
127.0.0.1:6320> set book2 def
OK

# set key value 成功，自動導向正確的Master節點操作
127.0.0.1:6320> set book3 ghi
-> Redirected to slot [14041] located at 127.0.0.1:6330
OK


# 透過 -c 來做Request Routing沒有辦法自動讀寫分離
# 設定唯讀模式，保持與replica連線
127.0.0.1:6330> readonly
OK

# 設定讀寫模式
127.0.0.1:6330> readwrite
OK

Redis效能監控與調教

Redis最差與最佳實踐

• 7種Redis的最差實踐
  • 沒有設定密碼
  • 任意執行keys * 操作
  • 太多資料庫
  • 執行HGETALL、LRANGE、SMEMBERS、ZRANGE時，沒有設定回傳限制
  • 一次連線只執行一個請求
  • Hot Keys
  • 沒有對Redis Server設定高可用性

7-redis-worst-practices

• Redis的最佳實踐
  • 避免儲存bigkey
  • 啟用lazyfree-*
  • 盡量不要使用時間複雜度 (Big O)高的操作
  • 如果需要執行時間複雜度為O(n)的指令時，請注意n的大小
  • 請注意DEL操作的時間複雜度
  • 使用批次操作取代多次單一操作
  • 不要在同一時間過期大量的key
  • 良好的連線管理
  • 建議只使用一個資料庫(db)
  • 建置Redis主從架構設定讀寫分離
  • 建置Redis 叢集
  • 關閉AOF或開啟AOF搭配everysec寫入
  • 使用實體主機安裝Redis
  • 建議關閉作業系統Hugepage機制

Redis效能測試與監控

• 取得基準效能
  • 建議抓取基準效能的2倍延遲當作監控

# --latency
# --latency-history
# --latency-dist
./redis-cli -h 127.0.0.1 -p 6310 --intrinsic-latency 60

• 效能測試(Benchmark)

# 在127.0.0.1:6310 啟用20個client測試10000個指令
./redis-benchmark -h 127.0.0.1 -p 6310 -n 10000 -q -c 20

# 參閱help
./redis-benchmark --help

benchmarks

• 透過慢日誌(Slowlog)取得需要被關注的記錄
  • 設定慢日誌
    • CONFIG SET slowlog-log-slower-than 1
      • 設定執行時間閥值為1毫秒
      • 預設為10毫秒，建議為1毫秒
    • CONFIG SET slowlog-max-len 500
      • 設定保留最近500筆記錄
      • 不要太小，建議1000
  • 顯示目前慢日誌筆數
    • SLOWLOG LEN
  • 清除慢日誌
    • SLOWLOG RESET
• 關注Memory實際使用狀況
  • 理論上used_memory_rss應該稍微大於used_memory而已

ps aux | grep redis-server
free
vmstat

• Redis的驅逐政策

  • volatile-lru
    • 根據LRU演算法刪除具有過期時間的Key
  • allkeys-lru
    • 根據LRU演算法刪除任何key
  • volatile-random
    • 隨機刪除具有過期時間的key
  • allkeys-random
    • 隨機刪除任何key
  • volatile-ttl
    • 根據最近過期時間及TTL刪除具有過期時間的Key
  • noevication

• 選擇合適的LRU

  • 如果有一部分使用頻率高，其餘部分使用頻率較少，或者無法預測資料的使用率．
    • allkeys-lru
  • 如果所有資料有大致相同的使用頻率
    • allkeys-random
  • 使用者自行通過不同的TTl來設定資料過期的順序
    • volatile-ttl
  • 如果某些資料希望可以長期保留
    • volatile-lru or volatile-random
  • 由於設定Expire會增加記憶體消耗，為避免浪費記憶體
    • allkeys-lru

• Redis Server的記憶體使用最佳化

  • 控制key的長度
  • 避免儲存bigkey
    • String建議在10kb以下
    • List/Hash/Set/Zset的元素個數建議在10000個以下
  • 使用適當的資料型態
    • String/Set資料型態在儲存int資料時，會使用整數編碼儲存
    • List/Hash/Zset資料型態在元素個數較少時，將使用ziplist型態儲存．資料較多時，才會使用Hashtable與skiptable
  • 將Redis Server當作快取使用而不是資料庫
  • 設定maxmemory與maxmemory-policy
  • 先壓縮再寫入Redis

• BGSAVE異常錯誤訊息

  • 因為進行bgsave時，會fork()一個子Process負責進行RDB操作．子Process使用copy-on-write機制共用父Process的記憶體內容，但如果父Process變更一塊記憶體內容，此時其變更前內容將複製到子Process的記憶體用以維持一致性．
  • 如果此時作業系統的overcommit_memory設定為0，而Redis Server已使用超過3G記憶體．所以執行bgsave時，Redis Server需要確定有超過3G可用記憶體．
  • 如果目前作業系統僅有2G可用記憶體，此時將無法fork()一個子Process進行bgsave，從而出現錯誤訊息

總結

Redis 在使用前需要先好好的思考應用的情境場景規劃適合自己應用的架構，搭配其特性進行操作可以提升應用程式的效率與提供良好的可靠度，這30篇只是一個分享的開始，還有很多的細節與應用情境的最佳實踐，個人目前還在努力的學習中，待我後續再與各位分享。謝謝各位的陪伴，祝福各位在學習路上一且順利．感謝！